Description

part of work on #5445
small survey of our caches:

• shortlived_cache: no eviction policy (bulk dropped on end of request)
• partial_request_cache: previously LRU, now LRU or LFU
• fd_cache_metrics: previously LRU, stays LRU. Given how this cache is used, i don't think anything else makes sense
• fast_field_cache: previously LRU, now LRU or LFU
• split_footer_cache: previously LRU, now LRU or LFU
• searcher_split_cache: previously LRU, still LRU. The cache policy logic is intertwined with how it background-fill itself, modifying it will require more work.

I chose to use moka because i believe it should be possible to re-express the searcher_split_cache using it, which wasn't the case for other most others crates i looked into. Its implementation is a tiny-lfu backed by an lru (essentially an lru with an lfu-based admission policy). This should behave well on changing workload (lru) while ignoring one hit wonders (lfu).

How was this PR tested?

updated tests. tested manually. Behavior on actual load will likely depend on the workload